[OPSAWG] Feedback on draft-ietf-opsawg-capwap-alt-tunnel-06

Andreas Schultz <aschultz@tpip.net> Mon, 01 February 2016 09:26 UTC

To: opsawg@ietf.org
From: Andreas Schultz <aschultz@tpip.net>
Message-ID: <56AF2496.1080601@tpip.net>
Date: Mon, 01 Feb 2016 10:25:42 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/opsawg/SXgQmj9pvN51gv06V3B5Osii2Oo>
Subject: [OPSAWG] Feedback on draft-ietf-opsawg-capwap-alt-tunnel-06
Precedence: list

Hi,

* Supported Alternate Tunnel Encapsulations

The Num_Tunnels field is redundant. This value can be derived from the IEs length since the Tunnel-Type is a fixed length value.

* Alternate Tunnel Encapsulations Type

Is differencing between GRE-IPv4 and GRE-IPv6 really needed?

The transport protocol can be derived from the type of the address IE. On the other hand, we might want to support GRE tunnels with
fall back to the other transport protocol (i.e. prefer IPv6 endpoint but fall back to IPv4).
I would suggest to simply calling it GRE and derive the transport protocol from the address IE and/or the resolved IP in case a FQDN was
specified.

* Alternate Tunnel Encapsulations Type Information Element

The IE format is quite different from the other IE's used in CAPWAP.

The content of any other CAPWAP IE only depends on the IE type. For this IE the content depends on the IE type *and* the tunnel type. I
would much prefer to keep this IE in line with the others and have one IE for the alternate tunnel type and additional IE's to specify the
tunnel parameters. This would also better suite tunnel protocols where you have optional arguments.

* AR FQDN List Element

No other CAPWAP IE does use FQDN's to specify IP endpoints. I don't see why we need to start here, the AC can always resolve FQDN's to IP's
and provision those.

* Alternate Tunnel Encapsulation Type

Reserving encapsulation types without specifying them completely seems a bit strange. But as long we do that, could we also reserve a type
for GTPv1-U (3GPP TS 29.281: http://www.3gpp.org/DynaReport/29281.htm)

Mobile networks use GTP already and 3GPP already defines mobile network to WiFi handover procedures. Supporting GTP alternate tunnels on
CAPWAP based WiFi AP would fit nicely into that.

Regards,
Andreas

[OPSAWG] Feedback on draft-ietf-opsawg-capwap-alt… Andreas Schultz